The present invention generally relates to managed environments in a data processing system and more specifically to optimization of working set adjustment in a managed environment of a virtual machine of the data processing system.
Heavily virtualized computing environments, for example, cloud computing, are designed to realize cost savings by maximizing density of applications enabled to run per unit of hardware. Maximizing density of applications improves utilization rates of the hardware and energy efficiency accordingly by eliminating idle machines.
In view of a significant portion of typical workloads being written using the Java® programming language specification the managed environment of a Java virtual machine (JVM) should recognize and exploit these virtualized environments. Java and all Java-based trademarks and logos are trademarks of Oracle Corporation, and/or its affiliates, in the United States, other countries or both. Maximization of application density typically requires the JVM to reduce a respective resource footprint, adapt to changing resource allocation, share more across JVM instances, and leverage hypervisor-specific functionality including fast guest-to-guest network fabric.
Java Virtual Machines have traditionally operated in what may be described as a “greedy” manner. The JVM often reserves resources up to a maximum allowed, even when the JVM does not necessarily need to do so. Further, once the JVM has used a resource, the resource is typically held assuming a subsequent later use. While this behavior is optimal while resources are fully available as is common in conventional environments, the practice however is not helpful with virtualized environments where over-provisioning is commonly used based on knowledge not all guests need maximum resource allocation concurrently.
An example of the current described behavior is a use of heap memory (memory used to store objects). Heap memory often grows, even when unused space exists on the heap, and then only slowly returns memory to the operating system, if at all. Over a period of time operating system memory allocated for an object heap in the JVM accordingly tends towards a maximum, as allowed when the JVM was started, although the JVM may only need the maximum for previously defined intervals (for example, between 9-10 users traditionally log into a particular application). Because returning memory to the operating system (for example when scanning, compacting) incurs a computational cost the JVM typically prefers to ‘hold’ extra memory rather than incurring a cleanup cost. Therefore, common practice advises customers never to simply avoid memory over-provisioning for Java applications, which accordingly reduces the value of virtualization.
Although there are few features to adjust heap sizes automatically using hints from hypervisors, memory pressure or other dynamic attributes in current commercial JVM implementations, published articles disclose these kinds of techniques. Techniques typically use a form of “balloon” to steal memory from a heap and return the memory to an operating system (or hypervisor) or adjust a maximum memory used by a collector to a value set using external factors. Each of the techniques has advantages and disadvantages described using a notation of Dn.
In one example using a balloon object, a required interaction with a JVM is minimized and does not require garbage collection (GC) activity to free memory. The disadvantage (D1) of this approach is the GC continues to manage the memory consumed by the balloon objects in the heap as normal objects, which accordingly adds overhead. In another example, when the GC moves objects (for example, during a compact operation) the GC may move the objects, also including the balloon object thus forcing the objects back into memory. The balloon object could detect this occurrence and free the memory but with additional overhead expended and memory pressure increased while the objects are moved (D2).
In another example in which a dynamically modified target for a heap is used an advantage is obtained in minimizing objects that must be handled by the GC. Minimizing objects that must be handled enables the GC to manage the objects optimally based on actual objects used by the application and a target available memory rather than being misled by special balloon objects. However a disadvantage (D3) of this example is the objects typically require relocation before memory can be freed and accordingly returned to the operating system. The GC activity required to move the objects therefore typically has an associated premium in the form of computation and paging overhead.